|
Heutige Unternehmen verwenden Workflow-Management-Systeme in
zunehmendem Maße zur Modellierung und Abwicklung ihrer
Geschäftsprozesse. Durch ihren Einsatz soll die Abwicklung der
Geschäftsprozesse als Workflows effizienter und effektiver
gestaltet werden. Mit der Verwendung eines Workflow-Management-
Systems entsteht für das Unternehmen gleichzeitig auch eine
weitreichende Abhängigkeit. Es ist darauf angewiesen, daß die
Ausführung der Workflows durch das Workflow-Management-System stets
zuverlässig und korrekt abgewickelt wird. Es muß gewährleistet
sein, daß im Falle eines Fehlers während der Workflow- Ausführung
keine Unternehmensdaten verfälscht oder verloren gehen. Das
Workflow-Management-System muß somit in der Lage sein, auf
Fehlersituationen angemessen zu reagieren und die Ausführung der
unterbrochenen Workflows fortzusetzen. Die Fähigkeit, auf Fehler zu
reagieren und sie zu beheben, um die Workflow-Ausführung
fortzusetzen, besitzen auf dem Markt befindliche Workflow-
Management-Systeme nicht oder nur unzureichend. Doch gerade bei
lange andauernden Vorgängen wie beispielsweise Geschäftsprozessen,
muß die Zuverlässigkeit der Ausführung sichergestellt sein. Im
Bereich der Datenbanken hat sich das klassische Transaktionskonzept
zur Modellierung von Abläufen bewährt. Es handelt sich dabei um
sehr kurze Vorgänge, die im Fehlerfall vollständig zurückgesetzt
werden. Zur Modellierung von lange andauernden Vorgängen wie
beispielsweise Geschäftsprozessen eignet sich das
Transaktionsmodell jedoch nur bedingt. Dies liegt an der strikten
Einhaltung der Atomaritäts- und Isolationseigenschaft einer
Transaktion. Die Atomarität einer Transaktion besagt, daß die
Transaktion entweder vollständig oder gar nicht ausgeführt wird.
Dies bedeutet, daß im Fehlerfall die gesamte Ausführung
zurückgesetzt wird und alle bereits ermittelten Zwischenergebnisse
verloren gehen. Für die Ausführung lange andauernder Vorgänge ist
dieses nicht akzeptabel. Die Isolationseigenschaft einer Transaktion
stellt sicher, daß die Ausführung einer Transaktion im logischen
Einbenutzerbetrieb erfolgt. Bei lange andauernden Vorgängen hat
dies zur Folge, daß sich durch konkurrierende Zugriffe auf
gemeinsam genutzte Datenbestände Wartezeiten und Deadlocks ergeben,
da die Daten für die gesamte Dauer der zugreifenden Transaktion
gesperrt bleiben. Zur Ausführung von lange andauernden Vorgängen,
wie beispielsweise Workflows, wird deshalb ein flexibleres
Ausführungsmodell als das klassische Transaktionsmodell benötigt.
Ein Beispiel hierfür ist das an der Universität Stuttgart
entwickelte ConTract-Modell. Es handelt sich hierbei nicht um eine
Erweiterung des klassischen Transaktionsmodells, sondern um ein
zweistufiges Programmiermodell, das auf der Verwendung von
ACID-Transaktionen aufbaut. Es ermöglicht die konsistente und
fehlertolerante Ausführung einer Reihe von elementaren
Bearbeitungsschritten (Steps) gemäß einer davon getrennt
festgelegten Kontrollflußbeschreibung (Skript). Sofern die in einem
Step ausgeführte Aktivität es ermöglicht, wird ein Step als
ACID-Transaktion ausgeführt. Im Gegensatz zum klassischen
Transaktionsmodell werden im ConTract-Modell auf Skript-Ebene die
Atomarität und die Isoliertheit abgeschwächt. Dies ermöglicht
einerseits das vorzeitige Externalisieren von Zwischenergebnissen,
jedoch resultiert daraus, daß im Fall einer Ausnahme oder eines
Fehlers das System nicht mehr in den exakten Zustand vor der
Step-Ausführung zurückversetzt werden kann. Statt dessen kann das
System durch die Ausführung weiterer Steps in einen Zustand
überführt werden, der aus der Sicht der Anwendung semantisch
äquivalent ist, oder die Ausführung des ConTract-Skriptes wird im
Fall eines Fehlers nach geeigneter Fehlerbehandlung nach vorne
fortgesetzt. Das Stornieren einer ConTract-Ausführung geschieht nur
auf Anweisung einer Benutzerin oder eines Benutzers, beziehungsweise
einer Anwendung. Besonders die Möglichkeit einer Fehlerbehandlung
liefert einen wesentlichen Beitrag zur Sicherstellung der
Fortsetzbarkeit eines ConTract. Die Fehlerbehandlung kann jedoch
nicht jeden beliebigen Fehlerfall abdecken. Sollte auf Grund eines
Fehlers die weitere Ausführung eines ConTract trotz durchgeführter
Fehlerbehandlung nicht mehr möglich sein, so wird der
Systemadministrator benachrichtigt. Er muß geeignete Maßnahmen
ergreifen, um die Fehlerursache zu beseitigen und die Fortsetzung
der ConTract-Ausführung ermöglichen. Liegt die Fehlerursache nicht
am technischen Umfeld der ConTract-Ausführung, sondern an der
ConTract-Definition, so muß das ConTract-Skript zur Laufzeit
korrigiert werden können, um die Fortsetzbarkeit der
ConTract-Ausführung zu ermöglichen. Diese Diplomarbeit untersucht
die Voraussetzungen unter denen das ConTract-Skript geändert werden
kann und welche Modifikationen zulässig sind, ohne die Konsistenz
der ConTract-Ausführung zu gefährden. Am Institut für Parallele
und Verteilte Höchstleistungsrechner (IPVR) der Universität
Stuttgart wird mit APRICOTS eine prototypische Implementierung eines
ConTract-verarbeitenden Systems durchgeführt, die speziell auf die
Ausführung von Workflows ausgerichtet ist. Zur Unterstützung der
Fortsetzbarkeit einer Workflow- Ausführung soll im Rahmen dieser
Diplomarbeit - als ein Teil des APRICOT- Systems - ein Werkzeug mit
graphischer Benutzungsoberfläche entwickelt werden, das die
Modifikation von Workflows zur Laufzeit ermöglicht. Es soll die
Benutzerin oder den Benutzer bei der Modifikation einer
Workflow-Instanz unterstützen und gleichzeitig die Konsistenz der
modifizierten Workflow-Instanz sicherstellen.
|